IBIS Macromodel Task Group Meeting date: 20 April 2021 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan * Todd Bermensolo * Rui Yang Luminous Computing * David Banas Marvell Steve Parker Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Hansel to submit his PAM4 Thresholds clarification BIRD to the Open Forum. - Done, submitted as BIRD212. - Randy to note in his email announcing the new BIRD212 that ATM recommends it be approved for IBIS 7.1. - Done. - Fangyi to send his "Combined Redriver Flow" presentation to the ATM list. - Done. - Walter to investigate whether any model vendors are generating legacy Tx models that optimize based on their downstream channel. - Done. Arpad noted that depending on which proposal we end up using this question might not be relevant. Walter agreed. He said he hadn't heard back from the model vendor he contacted, but he thought this issue would not be relevant to the new proposal he planned to review at this meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 13th meeting. Randy moved to approve the minutes. Arpad seconded the motion. There were no objections. ------------- New Discussion: BIRD210 and BIRD211: Walter noted that he had sent an email to ATM about another compromise solution to the Redriver flow, and he shared the "Tx_Impulse_Init" presentation it contained. He jumped straight to the key slide: - slide 4: Three flows This side illustrates 3 flows A, B, and C. - A: Walter said this is the minimal change to the IBIS 7.0 flow that corrects the existing Redriver flow problem. The output of Rx1 Init is combined with the output of Tx2 Init, and the result is passed in to Rx2 Init. This should be considered the default Redriver flow now, and he thought we all agreed on this. Walter said the other two flows are alternatives he's proposing to help in cases where they're needed. - B: In this flow the output of Rx1 Init is combined with the downstream channel, and the result is passed in to Tx2 Init. Walter said this flow is valuable for electrical channel Redriver models. If the Tx2 wants to optimize for the eye at the Rx2, it would have all the upstream and downstream information it needs. - C: In this flow the Tx2 Init receives its downstream channel's response and the output of Rx1 (cumulative upstream response) as separate columns in the impulse matrix. Walter said this is essentially what Fangyi had proposed in BIRD210, and it is required for some optical channels. - slide 5: New Reserved Parameter Tx_Impulse_Input This new parameter is Usage Info, and it tells the EDA tool what the Tx model expects for an input to Init. Original values on the slide were: - Downstream - legacy flow, the Init gets its downstream channel's response. - Upstream - Init gets its cumulative upstream response. - ~Adapt - (does not adapt) - all of the flows (A, B, C) yield the same answer if the Tx2 does not adapt. - Both - this is flow C, the Tx2 Init receives two separate columns with its cumulative upstream and downstream responses. Arpad said that "Both" to him implied together, not separate. Curtis asked what setting would be used for flow B, since it included the Downstream and Upstream together. Walter said the names of the four allowed values could be improved. David asked if "Legacy" would be a better name for the legacy (Downstream) case. Radek said "Legacy" was not a well-defined value because "Legacy" is a relative term. The group discussed new names for the 4 values and arrived at: - "7.0" - (later updated to "IBIS7.0" at Arpad's suggestion) - legacy flow. - "Combined" - flow B - cumulative upstream and the downstream are combined. - "Separate" - flow C - Column 1 contains the response of the Tx2's downstream channel, and a new column at the end of the impulse matrix contains the cumulative upstream response. - "DoNotCare" - Arpad's suggestion for the "does not adapt" case. The EDA tool can pass whatever it wants to the Tx2 Init as long as the EDA tool keeps track of how to combine everything in the end. Arpad reviewed some of the scenarios that had been problematic for earlier proposals. He asked if the A, B, and C flows all worked with crosstalk. Walter said they did. He said every Rx must have all of its aggressors' responses in its impulse matrix. For the Tx, he said the EDA tool could either put the impulse responses to the victims in the impulse matrix, or it could put the unit impulse response in the impulse matrix and use the filter response that was returned to compute all the combinations itself. Fangyi agreed, with the extra caveat that for Rx models the EDA tool should scale the unit impulse response with a small epsilon to ensure the fictitious crosstalk column did not affect an Rx that optimized based on crosstalk. Walter agreed, and he added that any model that optimizes based on crosstalk should probably be aware of any unit impulse response type crosstalk terms and ignore them when optimizing. Arpad asked to confirm that this proposal would work for optical channels. Fangyi agreed that flow C handled optical channels. Fangyi asked if we really needed flow B, since flow C give the model everything it needs. Walter said flow B is there because it's something you can do without requiring a brand new model. If you had a Tx2 that wanted to optimize itself based on everything that goes into the input at Rx2, then flow B would work. David agreed that the step from B to C is considerable, since flow C requires a new column and changes to AMI model boilerplate. Radek said we would be talking about a new Redriver model in any event, since it would have to use/support this new Tx_Impulse_Input parameter. Arpad said simply adding a new Info parameter to the .ami file is simpler than rewriting the executable model. Curtis said an existing Tx2 model that "works" with the legacy flow might prefer to have the combined upstream and downstream information available. If this were true, the model maker could simply add the new parameter with the value "Combined" to the .ami file. Walter said he had many model vendor customers who wanted to do just that, and their models asked the EDA tools to pass in the combined response. Arpad and David agreed this was a good reason to keep flow B as an option. Walter said that for the optical channels you would typically have 4 electrical signals (perhaps at 56Gbps each) coming into the optical part. It would combine them into one signal on the order of 2000Gbps, and send it ~ 1m (short run), or ~100m (medium), or ~35km (long haul). In modeling such a device, you would put the optical channel and all of its non-linearities in the Redriver model itself (either in the Tx executable model, the Rx executable model, or both). Fangyi said you could also have a pre-driver to model, so you might model the system with a cascaded chain of two Redriver models. Arpad asked if we could make the default value of the parameter match flow B instead. Fangyi said we want to preserve flow A and keep it the default so we don't change the default input to Tx2 and possibly break a legacy Tx2 model. Bob agreed that the default, including the case in which the parameter is not provided in the .ami file, should stay flow A. Radek said we have to carefully go over these flows and make sure they work when there is more than one Redriver in the chain. Walter said the new parameter only applies to the Txs, and he thought everything worked fine if Redrivers were chained. Walter to submit BIRD211.1 with this new proposal and the changes agreed upon during the meeting. - Curtis: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Walter to modify the new Redriver proposal as discussed during the meeting and submit it as BIRD211.1. ------------- Next meeting: 27 April 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives